✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues
✅	Licenses	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

This setting right now is only read when we start the app, so the experience is that the user changes the setting but doesn't observe the behavior change.

In my testing in both VSCode and Positron, when I use the "Quarto: Toggle Code Cells in Outline" command the change in the outline is instantly reflected. Are you not experiencing that in your testing? Or do you mean if the user changes the setting manually we should notify them to restart?

Or do you mean if the user changes the setting manually we should notify them to restart?

Yep, that's right. Right now, if the user changes the setting, nothing happens until the next time they close/open the app or reload the window. I think the best choice is to use vscode.workspace.onDidChangeConfiguration and a listener like if (event.affectsConfiguration("quarto.symbols.showCodeCellsInOutline")). A less good option that would still be acceptable is to put a note on the setting description that the user will need to restart VS Code/Positron to see the change in behavior.

It also would be worth re-examining the no-op edit hack and seeing if we can either:

• have the client send a workspace/didChangeConfiguration to the LSP to retrigger the outline generation, OR
• in the config listener, call vscode.commands.executeCommand("vscode.executeDocumentSymbolProvider", uri) on the active doc, so the toggle command just flips the setting, and the listener owns the refresh

@juliasilge I tried both the methods you mentioned and more, but was not able to get the outline to refresh without using the no-op edit hack (VSCode seems to have an outline cache that we can't bust without making an edit to the document?).

I've pulled out the no-op edit hack into onDidChangeConfiguration with if (event.affectsConfiguration("quarto.symbols.showCodeCellsInOutline")) like you suggested, so that we try to refresh the outline no matter how the config was changed.

I tested and this method of refreshing the outline seems to work well.

@juliasilge what do you think? Too hacky and we should tell the user to refresh or make an edit themselves? It seems to work well, so I think I would lean towards using the hack.

@vezwork I pushed 338c145 on top of your work that takes a different swing at the no-op edit hack, plus fixes a related cold-start bug that has been contributing to bad behavior in this area. We can revert that commit if we don't think this is a good way to go but I'd love to pitch you on this different approach! 😅

Part of the bad experience around the outline and why you were needing that no-op edit hack is that reloading the window (or opening VS Code with a previously-open .qmd restored) leaves the outline empty until you close and reopen the file. This was due to the same root cause as why your hack was needed in the first place:

apps/lsp/src/index.ts registers onDocumentSymbol in onInitialize, but mdLs isn't created until partway through onInitialized, after several awaits. Between those events, VS Code sends textDocument/documentSymbol, the handler returns mdLs?.getDocumentSymbols(...) || [] (empty), and VS Code caches that empty response. Without a document change to bust the cache, the outline stays empty until you close/reopen.

There are four main things to keep track of in my commit there:

1. Dynamic registration of the document symbol provider in onInitialized once mdLs exists, dropping the static documentSymbolProvider: true. Matches the pattern diagnostics.ts already uses. The capability simply isn't visible to VS Code until we can serve it, so the cold-start problem goes away.

2. Re-register on configManager.onDidChangeConfiguration to bust the client's symbol cache when the setting changes. The LSP spec has no workspace/documentSymbol/refresh, but re-registration is the spec-shaped equivalent. No more synthetic text edit firing onDidChangeTextDocument to every extension watching.

3. outline.expand after the re-query settles, in a new registerOutlineConfigListener in apps/vscode/src/main.ts. Re-registration causes VS Code to rebuild the tree collapsed (its heuristic when symbol shape changes), and outline.expand restores the visual state. The listener also handles the Settings UI path, too; if you change the setting while a non-Quarto tab is focused like the Settings tab, the expand waits until you switch back to a Quarto editor.

4. mdLsReady promise that onDocumentSymbol and onFoldingRanges await. Not strictly required for symbols anymore (dynamic registration handles it), but folding ranges has the same race so the gate is useful there too.

There are some tradeoffs compared to what you had in this PR. Your no-op edit hack approach preserved outline expansion state natively; mine loses it on re-registration and we have to explicitly restore it with outline.expand. I do think avoiding the no-op edit is better because the synthetic edit fires onDidChangeTextDocument to every extension watching the doc, and re-registration is the LSP-spec way to invalidate a symbol cache. There is a little remaining quirk still; when the user toggles "show cells", headers that were previously collapsed get expanded too. Probably fine since toggling is rare and most people doing it want to see the cells.

Take a look and see what you think! I'd love to get a better, less risky approach here.

I was also able to add tests for this in dc5b7cb.

@juliasilge I am completely sold on your pitch. Not only is your approach less hacky, it also feels nicer to use because the outline refreshes more immediately.

I refactored the code a lil bit:

• instead of waiting a magic 200ms before expanding the outline, instead we await vscode.commands.executeCommand("vscode.executeDocumentSymbolProvider", uri); to ensure document symbols are provided first. I think this should more reliably ensure the outline is populated before expanding it? In my testing it works.
• moved the outline expansion listener to symbols.ts.
• refactored away pendingExpand and the ongoing active text editor listener in favour of adding a active text editor change listener when the config changes, then expanding the outline and removing the listener once the user changes their active text editor to a qmd.
• removed some awaits that did not have any effect.

My one (maybe nitpick) concern is that if the user has multiple qmds open, only the first qmd they visit after changing their show/hide outline cells config will have an expanded outline. I tested and it is mildly annoying. I can't think of how to address that without expanding the outline of every qmd the user ever switches to. Maybe its okay to ignore this concern for now?

Overall I'm happy with where this PR is at now and would be down to merge if you are @juliasilge .

Thanks for the tests btw! Did you have any trouble getting them working??

(edit: maybe tests work now because your approach is less hacky!?)